record(intake): place five issues filed during the Nemotron campaign (#514, #515, #547, #569, #573) - #580

…514, #515, #547, #569, #573)

FOLLOWING_AGENTS_PROTOCOL

"No work without an open issue" only holds if the issue is reachable from the
intake surface. These five were filed and worked but never linked from the
roadmap table, so the table understated what is open and none of them was
findable from the place the protocol says to look.

#569 is the one that matters most and is already fixed on a branch: the
Nemotron revision pin was existence-only, so a directory holding a DIFFERENT
model resolved as long as a `trees/<rev>.json` manifest sat beside it -- and the
manifest can be empty. It is placed on the model row because it gates W6's
token-exact gate, which is exactly the instrument that cannot see a substituted
checkpoint.

#515 and #573 are both check-doc-checkpoint creating a shared-write surface, so
both go on ENG-RECORD-CONFLICT-SURFACES: the first classifies any root
CMakeLists.txt edit as a usage change, the second evaluates its obligation per
COMMIT rather than per change, which forced this campaign to squash a branch and
lose its RED-first history.

#514 is placed on ENG-RELEASE-WINDOWS: both windows-msvc jobs fail on EVERY pull
request while main stays green, because those jobs are skipped on push. That
makes CI unusable as a signal from the one place it is read.

#547 is left unplaced. It is a shared-seam defect -- GB10 reports
UnifiedMemory() true, so ReferenceTierEligible(kCUDA) installs the CPU host
kernel over cudaMalloc pointers where it needs DeviceMemoryIsHostAddressable()
-- and I am not confident which row owns the op-provider seam. The table
documents an em dash for exactly that case, and guessing a row would put wrong
data in a keyed record.

Records only, no product code touched.

Following-Agents-Protocol: true
AI-Assisted: true
Assisted-by: AGENT:claude-opus-5 [Claude Code]